In packet-switched computer networks, nodes such as hosts and routers use neighbor discovery (ND) signaling to determine link layer addresses of neighbors known to reside on attached links. In order to allow networks to exist beyond single links, it is common to use bridges to connect subnetworks that do not share a common link. ND proxies provide a method for bridging multiple links into a single network. They do this by modifying ND signaling passing through them. The Internet Engineering Task Force (IETF) has published a Request For Comments (RFC), RFC4389, entitled “Neighbor Discovery Proxies (ND Proxy)”, which describes a method by which multiple link layer segments are bridged into a single segment, through a proxy. RFC4389 specifies Internet Control Message Protocol (ICMP) Neighbor Solicitation and Neighbor Advertisement messages, used to enable hosts on either sides of a bridge to exchange addressing information to create bindings between Internet Protocol (IP) addresses and Media Access Control (MAC) addresses, the MAC addresses being also known as link layer addresses or layer 2 addresses. FIG. 1 (Prior Art) shows a simple network 100 comprising two subnetworks 110 and 150, connected through a bridge, which acts as a ND proxy 180. The subnetwork 110 comprises a first link layer connection 130, on which are connected several hosts such as a first host 120. Likewise, the subnetwork 150 comprises a second link layer connection 170, on which are connected several hosts such as a second host 160. The ND proxy 180 comprises ports connected to each of the first and second link layers 130 and 170. Each connection to one of the link layers comprises a MAC address. Hence, the first host 120 has a MAC address on the first link layer 130, the second host 160 has a MAC address on the second link layer 170, and the ND proxy 180 has two MAC addresses, one on each of the link layers. In order for the first host 120 to connect to the second host 160, without initially being aware of the MAC address of the second host 160, the first host 120 broadcasts a Neighbor Solicitation message comprising the IP and MAC addresses of the first host 120 and the IP address of the second host 160. The ND proxy 180 receives this Neighbor Solicitation message and may store the MAC address of the first host 120 in an internal cache. It forwards the Neighbor Solicitation message on the second link layer 170, after replacing the MAC address of the first host 120 inside the message with the MAC address of the ND proxy 180 on the second link layer 170. The second host 160 stores in a neighbor cache the IP address of the first host 120 in relation with the MAC address of the ND proxy 180 on the second link layer 170. The second host 160 then responds with a Neighbor Advertisement message placed on the second link layer 170, comprising the IP and MAC addresses of the second host 160 and, optionally, the IP address of the first host 120 and the MAC address of the ND proxy 180 on the second link layer 170. The ND proxy 180 detects the Neighbor Advertisement message of the second host 160, replaces the MAC address of the second host 160 with its own MAC address on the first link layer 130, replaces its own MAC address on the second link layer 170, if included, with the MAC address of the first host 120, and forwards the Neighbor Advertisement message on the first link layer 130. The first host 120 stores in a neighbor cache the IP address of the second host 160 in relation with the MAC address of the ND proxy 180 on the first link layer 110. If at any time later the first host 120 needs to communicate with the second host 160 by use of the IP address of the second host 160, its neighbor cache will indicate that any message or packet needs to be sent towards the MAC address of the ND proxy 180 on the first link layer 130. Likewise, if the second host 160 needs to communicate with the first host 120 by use of the IP address of the first host 120, the neighbor cache of the second host 160 will indicate that any message or packet needs to be sent towards the MAC address of the ND proxy 180 on the second link layer 170
RFC3971, entitled “SEcure Neighbor Discovery (SEND)”, specifies a method for securing neighbor discovery signaling against specific threats, such as malicious modification (spoofing) of addresses in Neighbor Solicitation and Neighbor Advertisement messages. The SEND protocol provides a way of securing ND signaling so that receiving nodes can detect if ND packets have been tampered with. Digital signatures are used to protect messages relating to neighbor discovery. Signatures protect the integrity of the messages and authenticate the identity of their sender by using certificates to prove the identity of message senders. In fact, each message comprises a signature based on a private key of the sender and on addresses of the sender. At a receiving end, the signature may be verified by use of a public key of the sender, the public key of the sender being certified to the receiving end by use of a query towards a trust anchor that is known and trusted by both the receiving end and the sender. Verification of the signature validates the addresses of the sender.
FIG. 2 (Prior Art) shows a format of a RSA signature. The RSA signature 200 is based on the well-known Rivest-Shamir-Adleman (RSA) algorithm and is specified in SEND. The RSA signature 200 is added to ND signaling messages. Bit markers 270 provide information regarding the format of the RSA signature 200. Fields included in the RSA signature 200 comprise:                Type 210: a value assigned by the IETF, and set equal to 12.        Length 220: A length of the RSA signature 200 (including all parameters in FIG. 2) in units of 8 octets.        Reserved 230: A 16-bit field, reserved for future use.        Key Hash 240: A 128-bit field containing the most significant (leftmost) 128 bits of a Secure Hash Standard-1 (SHA-1) hash of a public key used for constructing the RSA signature 200.        Digital Signature 250: A variable-length field containing a Public Key Cryptography Standards (PKCS) signature, constructed by using the sender's private key over the following sequence of octets:                    1. A 128-bit CGA Message Type tag value defined specifically for the SEND protocol.            2. A 128-bit Source Address field from an IP header of the ND signaling messages being protected by the SEND protocol.            3. A 128-bit Destination Address field from the IP header.            4. An 8-bit Type, 8-bit Code, and 16-bit Checksum fields from an Internet Control Message Protocol (ICMP) header of the protected message.            5. An ND proxy message header, starting from a first octet after an ICMP Checksum field and continuing up to but not including ND proxy specific parameters.            6. All ND proxy specific parameters preceding the RSA Signature 200. Specifically, these parameters comprise a link layer address of a node sending the ND message and, in the case where the ND message is a reply to another ND message, these parameters may also comprise a link layer address of a node towards which the message is intended.                        Padding 260: A variable-length field contains padding.        
All message parameters preceding the RSA signature 200 are included in the calculation of the digital signature 250. As a result, any “man in the middle” attack that might attempt to change some of these message parameters would be immediately detected by the receiving node upon verification of the signature.
SEND and ND Proxy are fundamentally incompatible because they are based on conflicting requirements. On one hand, as specified today, SEND assumes that a node advertising an IP address is the owner of the IP address and is in possession of the private key used to generate the digital signature based on the advertised IP address. On the other hand, with ND Proxy, the MAC address of the node which has initially advertised its IP address, and created a digital signature based on those IP and MAC addresses, is replaced within ND messages with a MAC address of the proxy. The digital signature of the original advertising node cannot be verified against its MAC address at the receiving end because that MAC address has been overwritten. In the presence of ND Proxy, the SEND protocol on the receiving end would infer that some malicious node may have tampered with original ND signaling when in fact it is a legitimate proxy that has modified the original ND signaling. RFC4389, which specifies “ND Proxy” and which was published in April 2006, after publication of the SEND RFC3971, expressly states that no mechanism is available for protection of proxy neighbor discovery processes. Proxy operation invalidates the RSA signatures, leading SEND-capable nodes that receive ND messages to either discard such messages or to treat them as unsecured.